home *** CD-ROM | disk | FTP | other *** search
- Date: Mon, 6 Jun 1994 12:48:35 -0400 (EDT)
- From: Timothy Miller <millert@undergrad.csee.usf.edu>
- Subject: Re: DEFAULT.SYS: Draft proposal, 4
- To: gem-list@world.std.com
- In-Reply-To: <199406052117.AA0358016641@relay2.geis.com>
- Message-Id: <Pine.3.87.9406061234.C19709-0100000@undergrad>
- Mime-Version: 1.0
- Precedence: bulk
-
-
-
- On Sun, 5 Jun 1994 s.sanders2@genie.geis.com wrote:
-
- > Reply: Item #7176694 from GEM-LIST-APPROVAL@WORLD.STD.COM@INET00#
- >
- > I've got a few ideas I'd like to share...
- >
- > IMHO it's probably a bad idea to require each application to parse a
- > KEYBIND.SYS (or whatever) file individually. This leads to extra work
- > (which means fewer people use it) and undoubtedly some programs will
- > have bugs in _their_ parse code making them less portable between
- > machines.
-
- Agreed.
-
- >
- > The solution (and forgive me if this was meant to be 'doubly'
- > implemented) is a global key definition array in memory. Let a
- > Resident CPX or TSR define a cookie whose pointer points to an array
- > like this:
- >
- > typedef struct _keydef_cookie
- > {
- > short func_code; /* As suggested 0-999 general, etc */
- > short key_code; /* Key equivalent */
- > short key_kbstate; /* Mask of required state */
- > } KEYDEF_COOKIE;
- >
- > KEYDEF_COOKIE keysdefs[...];
- >
- > The array would be terminated by 0xFFFF func_code entry.
- >
- > -Scott @ SDS
-
- What should key_code be? A hardware scan-code? That will be different
- on different keyboards. Certainly not an ascii code either since that
- wouldn't distinguish between Return/^M, Backspace/^H, etc. Must we now
- come up with ANOTHER standard for what values correspond
- (internationally) to what keys?
-
-
-